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1 Introduction 


The  mapping  table  is  a pivotal  component  of  an  application  protocol  (AP).  The  mapping  table  documents  the 
traceability  of  the  application  information  requirements  between  the  specification  of  these  requirements  in 
clause  4 of  the  AP  and  the  application  interpreted  model  (AIM)  that  documents  how  standardized  constructs 
are  applied  to  satisfy  these  requirements  in  clause  5.  This  document  is  intended  to  provide  guidance  to 
application  protocol  development  teams  on  the  creation  of  mapping  tables.  Additionally,  this  document  may 
aid  reviewers  and  implementors  of  APs  in  understanding  mapping  tables.  This  document  describes  the 
methodology  for  producing  a complete  mapping  table,  focusing  on  the  development  of  the  mapping  table 
content.  Specifics  on  style,  format,  boiler  plate  text,  and  other  presentation  issues  are  provided  in  the 
Supplementary  directives  for  the  drafting  and  presentation  of  ISO  10303  (Supplementary  directives). 
Additional  guidance  on  other  areas  of  AP  development  is  found  in  the  Guidelines  for  development  and 
approval  of  STEP  application  protocols. 

Each  information  requirement  of  an  AP  is  mapped  to  one  or  more  constructs  in  the  AIM.  Each  of  these 
mappings  is  documented  on  a single  row  of  the  mapping  table.  The  mapping  table  is  organized  into  sub-tables 
by  unit  of  functionality  (UoF)  as  defined  in  clause  4.1  of  the  AP.  Each  row  is  divided  into  five  columns  that 
provide  the  details  of  the  mapping.  The  headings  of  the  five  colunms  are  Application  element,  AIM  element. 
Source,  Rules,  and  Reference  path.  This  document  provides  guidance  on  the  development  of  each  column 
of  the  mapping  table. 

To  aid  in  the  understanding  of  this  document,  several  examples  taken  from  ISO  10303-201:1994  (part  201) 
are  included  within  the  body  of  this  text.  Additionally,  a more  comprehensive  example  is  provided  in  the 
annexes  of  this  document.  In  the  example  shown  in  annexes  A and  B,  four  apphcation  objects  have  been 
chosen  from  one  of  the  UoFs  in  part  201.  Annex  A contains  the  descriptions  of  the  UoF,  the  application 
objects,  and  the  application  assertions  as  normatively  documented  in  clause  4 of  part  201.  Annex  B contains 
the  mapping  table  for  the  application  objects  and  assertions  in  annex  A.  Throughout  the  body  of  this  text, 
references  to  application  elements  in  examples  are  presented  with  leading  capitals  and  underscores  between 
the  words.  References  to  AIM  elements  in  examples  are  presented  in  bold  face  with  underscores  between 
words,  but  no  leading  capitals. 


2 Application  element  column  documentation 


The  Application  element  column  lists  the  application  objects  (i.e.,  entities  and  attributes)  and  assertions  from 
clause  4 of  the  AP  in  accordance  with  the  guidance  provided  in  the  Supplementary  directives.  Each 
application  element  from  the  application  protocol  appears  at  least  once  in  the  table.  An  application  object  may 
appear  in  more  than  one  UoF  within  an  AP.  When  this  occurs,  the  sub-table  for  each  UoF  documents  the 
mapping  of  that  element  within  the  context  of  that  UoF. 

The  requirements  of  the  application  protocol  may  define  more  than  one  assertion  between  two  apphcation 
objects.  When  this  occurs,  each  assertion  is  entered  on  a separate  row  of  the  mapping  table.  The  heading  of 
the  apphcation  assertion  from  clause  4.3  of  the  AP  is  used  for  each  entry  along  with  an  identifying  phrase. 
The  phrase  is  chosen  from  the  normative  text  of  the  assertion  and  is  placed  in  parentheses  following  the 
assertion  heading.  The  assertions  appear  in  the  mapping  table  in  the  order  that  they  are  defined  in  clause  4.3 
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of  the  AP.  Figure  1 illustrates  how  three  assertions  between  a pair  of  application  objects  are  documented  in 
the  first  column  of  a mapping  table. 


43.67  Stnictured_dimension_callout  to  Text_string 

Each  Structured_dimension_callout  has  as  a dimension  value  one  or  more  Text_string  objects.  Each 
Text_string  may  be  the  dimension  value  for  exactly  one  Structured_dimension_callout. 

Each  Structured_dimension_callout  has  as  a tolerance  value  zero,  one,  or  many  Text_string  objects.  Each 
Text_string  may  be  the  tolerance  value  for  exactly  one  Structured_dimension_callout. 

Each  Structured_dimension_callout  has  as  unit  text  zero,  one,  or  many  Text_string  objects.  Each  Text_- 
string  may  be  the  unit  text  for  exactly  one  Structured_dimension_callout. 


Application  element 

STRUCnJRED_DIMENSION_CALLOUT 

structured_dimension_callout  to  text_string 
(as  dimension  value) 

structured_dimension_callout  to  text_string 
(as  tolerance  value) 

structured_dimension_callout  to  text_string 
(as  unit  text) 

Figure  1 - Example  of  multiple  assertions 


When  an  application  object  maps  to  different  AIM  objects  in  different  contexts,  often  the  mappings  can  be 
clearly  documented  only  through  the  use  of  numbered  alternatives  within  the  row  of  the  mapping  table.  In 
these  cases,  the  application  element  column  contains  numbered  descriptions  that  indicate  when  the  alternative 
mappings  apply.  In  the  succeeding  columns  of  the  table,  the  AIM  elements  and  reference  paths  are  numbered 
correspondingly.  In  practice,  when  there  are  multiple  mappings  for  an  application  object,  these  mappings  are 
frequently  self-explanatory.  However,  mappings  of  assertions  involving  this  object  and  attributes  of  this 
object  generally  require  the  numbered  descriptions.  Figure  2 shows  alternative  mappings  for  an  application 
object  that  requires  clarification.  In  the  example  in  annex  B,  the  entity  Organization  has  multiple  mappings, 
though  numbered  alternatives  are  only  provided  for  the  mappings  of  the  Organization_name  attribute  and  the 
assertion  from  Approval  to  Organization. 
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Application  element 

AIM  element 

Source 

ANNOTATION_SUBnGURE_ 

#1  (draughting_armotation_ 

201 

DEnNrnON_ELEMENT 

occurrence) 

#1 : If  the  element  is  a curve,  fill 
area,  symbol,  subfigure,  or  text 
#2:  If  the  element  is  a dimension 
or  a draughting  callout 

#2  (draughting_elements) 

201 

annotation_subfigure_ 
defirution_element  to 
draughting_aruiotation 

IDENTICAL  MAPPING 

Figure  2 - Example  of  alternative  mappings 


3 AIM  element  column  documentation 


The  AIM  element  column  contains  the  description  to  which  the  application  element  from  the  preceding 
column  maps.  Application  objects  map  to  either  a single  AIM  element,  a combination  of  multiple  AIM 
elements,  or  a choice  among  multiple  AIM  elements.  AIM  elements  are  entities  or  attributes  from  resource 
models  (i.e.,  integrated  resources  or  application  inteipreted  constructs)  or  entities  that  are  defined  in  the  AIM 
of  the  AP  being  mapped.  The  AIM  element  column  for  an  application  assertion  is  populated  with  the  word 
“PATH”  or  the  words  “IDENTICAL  MAPPING”.  These  mappings  are  described  in  the  following  sub- 
sections. 

3.1  Single  AIM  element 

Application  objects  may  map  to  entities  or  attributes  from  the  integrated  resources,  application  interpreted 
constmcts,  or  entities  created  within  the  AIM  short  form.  When  the  mapping  is  to  an  entity,  the  entity  name 
appears  in  the  AIM  element  column.  When  the  mapping  is  to  an  attribute,  the  AIM  element  column  contains 
the  entity  name  where  the  attribute  is  defined,  followed  by  a period,  followed  by  the  attribute  name. 

3.2  Multiple  AIM  elements 

Sometimes  a single  application  object  maps  to  more  than  one  AIM  element.  When  this  occurs,  each  moping 
is  documented  in  the  mapping  table.  This  may  occur  as  an  “and”  situation  (both  AIM  elements  must  be 
present)  or  an  “or”  situation  (either  AIM  element  may  be  present).  In  an  “and”  mapping,  multiple  AIM 
elements  are  required  to  satisfy  the  information  requirement.  Square  brackets  “[]”  are  placed  around  each 
required  AIM  element  to  denote  the  “and”  situation.  In  an  “or”  situation,  multiple  AIM  elements  are 
alternatives  that  satisfy  the  information  requirements.  Parentheses  “()”  are  placed  around  each  alternative  AIM 
element  to  denote  the  “or”  situation.  Often,  the  alternatives  in  an  “or”  situation  are  numbered  to  reflect 
descriptions  provided  in  the  application  element  column.  Parentheses  and  brackets  may  be  used  in 
combination  to  indicate  the  mapping  of  compound  “and”/“or”  situations. 

For  an  example  of  an  attribute  with  multiple  mappings,  see  the  Organization_name  attribute  of  the 
Organization  application  object  in  annex  B.  In  this  mapping,  how  the  requirement  for  a name  is  satisfied 
depends  on  whether  the  organization  is  satisfied  as  a person,  an  organization,  or  a person  within  an 
organization  and  is  thus  indicated  by  parentheses.  When  a person  within  an  organization  is  required,  the  name 
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is  satisfied  by  both  the  identification  of  the  person  and  the  name  of  the  organization  as  indicated  by  the  square 
brackets. 

3.3  Path 

The  AIM  element  column  of  a mapping  table  contains  the  word  “PATH”  when  the  application  element  is  an 
application  assertion  and  the  application  objects  in  the  assertion  map  to  different  AIM  elements.  The  reference 
path  for  an  application  assertion  is  designed  to  show  how  the  relationship  between  the  application  objects  is 
satisfied  in  the  AIM. 

3.4  Identical  mapping 

The  AIM  element  column  of  a mapping  contains  the  words  “IDENTICAL  MAPPING”  when  the  application 
element  is  an  application  assertion  and  both  application  objects  in  the  assertion  map  to  the  same  AIM  element 
(see  Figure  3).  Such  cases  may  arise  when  there  is  a high  level  of  detail  in  the  application  reference  model 
(ARM)  or  the  constructs  in  the  integrated  resources  are  more  semantically  rich  than  the  constructs  in  the  ARM. 


Application  element 

AIM  element 

Source 

ANNOTATION_SUBFIGURE_ 

#1  (draughting_annotation_ 

201 

DEFINrnON_ELEMENT 

occurrence) 

#1 : If  the  element  is  a curve,  fill 
area,  symbol,  subfigure,  or  text 
#2:  If  the  element  is  a dimension 
or  a draughting  callout 

#2  (draughting_elements) 

201 

annotation_subfigure_ 
definition_element  to 
draughting_annotation 

IDENTICAL  MAPPING 

DRAUGHTING_ANNOTATION 

#1  (draughting_annotation_ 

201 

#1:  If  the  aimotation  is  a curve,  fill 

occurrence) 

area,  symbol,  subfigure,  or  text 
#2:  If  the  annotation  is  a 
dimension  or  a draughting 
callout 

#2  (draughting_elements) 

201 

Figure  3 - Example  of  an  identical  mapping 

4 Source  column  documentation 


The  Source  column  contains  an  ISO  10303  part  number  for  each  AIM  element  provided  in  the  preceding 
column.  In  general,  the  part  number  is  the  part  of  ISO  10303  in  which  the  AIM  element  is  defined.  The  part 
numbers  referenced  in  a mapping  table  may  correspond  to  an  integrated  resource  (IR);  an  apphcation 
interpreted  construct  (AIC);  or  the  application  protocol  itself,  in  the  case  where  the  AIM  element  is  an  AP 
created  specialization  of  an  integrated  resource  entity.  When  an  application  object  or  assertion  is  mapped  to 
an  entity  or  type  that  is  defined  in  the  integrated  resources,  implicitly  or  explicitly  brought  into  the  scope  of 
an  AIC  according  to  the  interfacing  rules  of  the  EXPRESS  language  reference  manual  (ISO  10303-1 1:1994), 
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and  the  mapping  is  within  the  context  of  the  AIC,  the  AIC  part  number  is  referenced  in  the  source  column. 
If  the  mapping  is  not  within  the  context  of  the  AIC,  the  part  number  of  the  integrated  resource  construct  is 
referenced  in  the  source  column. 

If  the  AIM  element  column  contains  either  the  word  “PATH”  or  the  words  “IDENTICAL  MAPPING”,  no 
source  document  is  listed  in  the  source  column. 


5 Rules  column  documentation 


The  Rules  column  of  the  mapping  table  contains  numerical  references  to  the  global  rules  in  the  AIM  short 
form  that  constrain  the  mappings.  The  numerical  references  correspond  to  a numbered  hst  of  all  global  rules 
in  the  AP.  That  list  follows  the  mapping  table.  In  this  list,  the  rules  shall  appear  in  the  same  order  as  in  clause 
5.2.3  of  the  AP.  There  may  be  more  than  one  rule  constraining  a given  mapping.  Some  mappings  may  be 
unconstrained.  Rules  restricting  instantiation  of  entities  within  the  AIM  are  to  be  included  in  the  mapping 
table  only  when  the  mapping  is  to  an  AIM  element  that  shall  not  be  independently  instantiable.  When  an 
entity  constrained  by  an  instantiability  rule  appears  in  a reference  path,  that  mapping  assumes  that  the  entity 
will  be  instantiated  in  the  context  of  other  entities;  therefore,  the  reference  to  the  rule  is  not  needed  for  that 
mapping.  All  mles  that  are  created  in  the  AP  short  form,  with  the  exception  of  entity  instantiability  rules,  must 
be  referenced  in  the  mapping  table  at  least  once. 


6 Reference  path  column  documentation 


The  reference  path  illustrates  how  the  requirements  and  relationships  stated  in  clause  4 of  the  AP  are 
maintained  as  a result  of  the  apphcation  interpretation  process.  It  specifies  the  complete  path  of  entity 
references  in  the  AIM  that  is  needed  to  represent  the  information  requirements  of  the  ARM.  A set  of  symbols 
and  formats  were  developed  to  construct  a consistent  syntax  for  documenting  reference  paths.  Reference  path 
syntax  is  consistent  for  each  type  of  application  element.  The  intent  of  the  current  syntax  is  to  facilitate  human 
readability  of  the  mapping  table.  In  the  future,  this  syntax  may  be  extended  to  improve  computer  readability 
of  the  mapping  table.  This  section  discusses  the  symbology  used  in  documenting  reference  paths  as  well  as 
reference  path  requirements  for  each  type  of  application  element. 

6.1  Symbology 

A reference  path  specification  is  contained  within  a single  cell  in  the  reference  path  column  of  the  mapping 
table  and  is  read  from  top  to  bottom.  Each  line  of  the  reference  path  specification  may  contain  symbols  to 
illustrate  the  EXPRESS  stracture  of  the  AIM  objects.  Understanding  the  symbology  used  in  the  reference  path 
specification  is  the  key  to  reading  and  writing  mapping  tables. 

6.1.1  Delimiter  symbols 

The  delimeter  symbols  are  used  to  indicate  the  relationship  of  the  specified  entity  or  attribute  preceding  the 
symbol  to  the  specified  entity  or  attribute  following  the  symbol.  The  symbol  should  be  placed  at  the  end  of 
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the  line,  so  that  the  name  of  the  following  entity  or  attribute  is  at  the  beginning  of  the  next  line.  The  meaning 
of  these  symbols  can  be  paraphrased  as: 


=> : 

“is  a supertype  of’ 

<= : 

“is  a subtype  of’ 

-> : 

“references” 

<- : 

“is  referenced  by” 

The  “=>”  and  “<=”  symbols  indicate  a supertype  or  subtype  structure.  The  “=>”  symbol  is  used  to  indicate 
that  the  specified  entity  preceding  the  symbol  is  the  supertype  of  the  entity  specified  on  the  next  line.  The 
“<=”  symbol  is  used  to  indicate  that  the  specified  entity  preceding  the  symbol  is  a subtype  of  the  entity 
specified  on  the  next  line. 

The  and  symbols  indicate  the  reference  to  an  entity  or  type  by  an  attribute.  The  symbol  is  used 
to  indicate  that  the  specified  attribute  preceding  the  symbol  references  the  entity  or  type  specified  on  the  next 
line.  The  symbol  is  used  to  indicate  that  the  specified  entity  or  type  preceding  the  symbol  is  referenced 
by  the  attribute  specified  on  the  next  line. 

When  an  entity  name  appears  on  a line  that  is  terminated  without  the  use  of  one  of  the  above  symbols,  this 
may  indicate  that  the  specified  entity  has  the  attribute  shown  on  the  next  line.  When  an  attribute  name  appears 
on  a line  that  is  terminated  without  the  use  of  one  of  the  above  symbols,  this  may  indicate  that  the  specified 
attribute  is  an  attribute  of  the  entity  shown  on  the  next  line.  A new  line  is  used  without  conveying  additional 
semantics  before  and  after  lines  where  a select  type  value  is  provided.  A new  line  also  terminates  the  reference 
path. 

Reference  path  lines  that  are  too  long  to  fit  within  the  table  cell  can  be  split  using  the  forward  slash  symbol 
“/”.  The  symbol  conveys  no  additional  meaning  within  the  reference  path.  The  “/”  is  positioned  between 
elements  of  the  line,  preferably  in  white  space.  The  “/”  may  appear  between  an  entity  and  an  attribute, 
following  the  period,  but  this  case  should  be  avoided  where  possible. 

6.1.2  Aggregation  symbols 

If  an  attribute  references  an  aggregate  cardinality,  and  any  single  instance  of  the  aggregate  is  of  interest, 
brackets  and  the  letter  i “[i]”  are  used  to  indicate  this.  The  use  of  “[n]”  (where  n is  an  integer)  indicates  that 
member  n of  the  aggregate  is  of  interest  in  the  mapping.  In  order  to  limit  the  number  of  elements  in  an 
instantiation  of  the  aggregation,  rules  must  be  written  in  the  short  form  of  the  AIM.  In  the  mapping  of  the 
Drawing  to  Approval  assertion  in  aimex  B,  the  attribute  appro ved_items  is  a set  that  references  the  select  type 
approved_item. 

6.1.3  Equal  sign 

An  equal  sign  “=”  is  used  in  the  reference  path  specification  to  indicate  a member  of  a select  list,  an 
enumerated  item  of  an  enumerated  list,  or  a specific  value  for  an  attribute.  In  the  case  of  a select  list,  the  name 
of  the  select  type  appears  first  followed  on  the  same  line  by  the  equal  sign  and  the  member  that  is  being 
selected.  In  the  case  of  an  enumerated  list,  the  name  of  the  enumeration  type  appears  first  followed  on  the 
same  line  by  the  equal  sign  and  the  enumerated  item.  In  the  case  of  a specific  value,  the  attribute  name 
appears  first  followed  on  the  same  line  by  the  equal  sign  and  the  value  assigned  to  the  attribute. 
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See  the  mapping  of  the  Date  attribute  of  the  Approval  object  in  annex  B.  In  this  reference  path  specification, 
tlie  attribute  date_time  references  the  select  type  date_time_select.  For  this  mapping,  the  selection  is  a date. 
As  seen  in  this  example,  the  name  of  the  select  type  appears  on  the  line  before  the  line  containing  the  equal 
sign,  and  the  selected  member  appears  on  the  line  following  the  line  containing  the  equal  sign.  The  order  of 
these  lines  is  reversed  for  a reference  path  in  which  the  selected  member  is  referenced  first  in  the  path.  See 
the  mapping  of  the  Drawing  to  Approval  assertion  in  the  example  in  annex  B.  In  this  mapping,  the  reference 
path  encounters  drawing_revision  first,  which  is  the  selected  member  of  the  approved_item  select  type. 

6.1.4  Parentheses 

Parentheses  “( )”  are  used  to  indicate  the  existence  of  options  in  the  reference  path.  Each  option  is  enclosed 
by  a set  of  parentheses.  The  parentheses  are  used  to  indicate  that  a mapping  has  multiple  reference  paths  or 
sections  of  the  reference  path.  There  are  two  reasons  that  the  reference  path  may  diverge:  an  object  is  mapped 
to  multiple  AIM  entities  or  the  reference  path  depends  on  the  instantiation  of  the  AIM.  To  aid  understanding, 
the  optional  sections  of  the  path  may  be  numbered  and  a description  provided,  with  the  application  object,  that 
gives  the  reason  for  the  divergence. 

See  the  mapping  of  the  Approval  to  Organization  assertion  in  annex  B.  In  this  example,  it  is  necessary  to 
show  the  reference  paths  for  each  of  the  AIM  elements  to  which  the  Organization  maps. 

6.1.5  Square  brackets 

Square  brackets  “[  ]”  are  used  to  indicate  two  or  more  required  sections  of  the  reference  path.  The  square 
brackets  indicate  that  there  are  either  multiple  mappings  or  multiple  paths  required  to  satisfy  the  mapping. 
Each  mapping  or  path  is  enclosed  by  a set  of  square  brackets.  To  fully  document  how  the  requirements  are 
satisfied  by  the  mapping,  sections  of  the  path  may  be  numbered  and  a description  giving  the  reason  for  the 
divergence  may  be  provided  in  the  Application  element  column. 

See  the  mapping  of  the  Annotation_subfig;ure_definition  to  2D_cartesian_coordinate_space  assertion  in  the 
example  in  Figure  4.  This  example  shows  that  every  representation_context  that  satisfies  the  requirements 
of  the  application  object  2D_cartesian_coordinate_space  must  be  both  a geometric_representation_context 
and  a globaI_uiiit_assigned_context.  See  the  mapping  of  the  Organization_name  attribute  of  Organization 
in  annex  B.  Where  the  mapping  is  to  a person  within  an  organization,  both  reference  paths  shown  are 
required. 

6.1.6  Braces 

Braces  “{  }”  are  used  to  indicate  constraints  placed  on  the  mapping.  This  notation  is  used  when  the  reference 
path  specification  would  not  normally  contain  AIM  entities  which  are  crucial  to  the  mapping.  Braces  may  be 
used  to  include  into  the  reference  path  specification  required  supertypes  or  subtypes,  required  values  assigned 
to  attributes,  or  AIC  entities  containing  rules  that  constrain  the  mapping.  See  the  mapping  of  the  Structured_- 
dimension_callout  to  Draughting_callout  assertion  in  the  example  in  Figure  3.  In  this  example,  the  reference 
path  specification  would  not  normally  show  the  part  201  created  subtype.  However,  for  this  mapping,  the  only 
draughting_calIout_relatioiiship  that  satisfies  the  information  requirement  is  the 
dimension_callout_component_relationship  subtype.  The  second  usage  of  the  braces  in  the  reference  path 
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specification  indicates  that  the  name  of  the  relationship  is  restricted  for  this  mapping  to  have  the  value 
“prefix”. 

Braces  are  also  used  if  an  assertion  is  mapped  to  a specialization  of  a resource  entity  and  the  reference  path 
specification  would  not  otherwise  show  the  resource  entity.  The  inclusion  of  these  AIM  elements  is  intended 
to  satisfy  the  requirement  that  all  mappings  to  a specialized  entity  must  have  a reference  path  to  a resource 
entity. 

6.2  Application  objects 

A reference  path  specification  is  necessary  for  each  application  object  that  is  mapped  to  a specialization  of  an 
integrated  resource  entity.  The  reference  path  starts  with  the  AIM  element  to  which  the  application  object  is 
mapped.  It  concludes  at  the  integrated  resource  entity  of  which  the  specialization  is  a subtype.  See  the 
mapping  of  Drawing  in  annex  B.  In  this  example,  Drawing  is  mapped  to  draughting_drawing_revision, 
which  is  a subtype  of  drawing_revision  in  ISO  10303-101 : 1994  (part  101).  The  reference  path  contains  these 
two  entities. 

A reference  path  can  also  be  shown  to  clarify  a restriction  on  the  mapping.  See  the  mapping  of  Annotation_- 
subfigure_definition  in  the  example  in  Figure  4.  This  object  maps  to  an  entity  in  the  integrated  resources; 
therefore,  no  reference  path  specification  is  required.  However,  to  satisfy  the  requirements  for  this  mapping, 
the  inherited  attribute  mapped_representation  must  be  of  type  draughtmg_subfigure_representation.  This 
restriction  is  shown  by  including  this  portion  of  the  reference  path  specification  within  braces. 

6.3  Application  attributes 

There  are  different  mappings  of  an  attribute  that  must  be  considered  for  the  documentation  of  the  reference 
path.  An  attribute  may  be  mapped  to  an  attribute  of  the  same  AIM  entity  to  which  the  application  object  is 
mapped.  In  this  case,  no  reference  path  is  necessary  for  the  attribute.  See  the  mapping  of  the  Description 
attribute  of  Approval  in  the  example  in  annex  B. 

An  attribute  may  be  mapped  to  an  attribute  of  an  entity  different  from  the  one  to  which  the  application  object 
is  mapped.  The  reference  path  for  the  attribute  starts  with  the  AIM  element  to  which  the  application  object 
is  mapped.  The  path  follows  the  entities  and  attributes  of  the  AIM  to  the  AIM  attribute  to  which  the 
application  attribute  is  mapped.  See  the  mapping  of  the  Drawing_number  attribute  of  Drawing  in  the  example 
in  annex  B.  In  this  example.  Drawing  is  mapped  to  draughting_drawmg_revisioii  so  the  reference  path  of 
Drawing_number  begins  with  this  entity.  Drawing_revision  has  an  attribute  drawing_identifier  that 
references  the  entity  drawiiig_defimtion.  The  drawing_defiiiition  entity  has  an  attribute  drawmg_number 
to  which  the  drawing_number  attribute  is  being  mapped. 


6.4  Application  assertions 

Application  assertions  specify  the  relationships  between  pairs  of  application  objects,  the  cardinality  of  the 
relationships,  and  the  rules  required  for  the  integrity  and  validity  of  the  application  objects. 
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Figure  5 - Example  of  braces 


The  reference  path  of  an  assertion  starts  with  the  AIM  element  to  which  the  first  application  object  is  mapped. 
The  path  concludes  at  the  AIM  element  to  which  the  second  apphcation  object  in  the  assertion  is  mapped.  See 
the  mapping  of  the  Drawing  to  Approval  assertion  in  annex  B.  In  this  example,  Drawing  is  mapped  to 
draughting_drawing_revision  so  the  reference  path  of  the  assertion  begins  with  this  entity.  Drawing_- 
revision  is  one  of  the  approved_items  to  which  approval  is  assigned. 

If  the  AIM  element  column  contains  the  words  “IDENTICAL  MAPPING”,  no  reference  path  specification 
is  required. 

In  rare  cases,  an  application  assertion  may  map  to  an  AIM  entity  or  attribute.  In  these  cases,  the  mapping  may 
be  to  an  attribute  in  the  reference  path  that  connects  the  two  identified  application  objects,  or  to  an  AIM  entity 
that  acts  as  the  intersection  entity  connecting  the  two  identified  apphcation  objects.  This  attribute  or  entity 
is  selected  for  the  AIM  element  column  with  agreement  by  the  AIM  interpretation  committee.  The  source 
column  contains  the  number  of  the  part  containing  this  entity  or  attribute. 

6.5  AIC  considerations 

AICs  define  “root  node”  entities  where  global  rules  pertaining  to  the  AIC  have  been  localized.  If  the  root  node 
of  the  AIC  includes  restrictions  that  apply  to  the  mapping,  the  root  node  shall  be  included  in  the  reference  path 
specification  to  indicate  this,  even  if  the  inclusion  is  only  with  the  braces  notation. 
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Annex  A 


Example  information  requirements 


This  annex  contains  the  normative  descriptions  of  the  UoF,  the  appUcation  objects,  and  the  apphcation 
assertions  for  the  example.  These  descriptions  are  extracted  from  clause  4 of  ISO  10303-201:1994.  Some 
objects,  attributes,  and  assertions  from  the  UoF  have  been  excluded  from  the  example. 

4.1  Units  of  functionality 

4.1.4  drawing_structure_and_administration 

The  drawing_structure_and_administration  UoF  contains  information  about  the  hierarchical  organization  of 
drawings,  drawing  sheets,  and  drawing  views,  together  with  the  administrative  information  necessary  to 
manage  drawings  and  drawing  sheets.  Drawing  sheets  and  drawing  views  are  defined  in  their  specific 
coordinate  space.  Annotation  may  be  assigned  to  each  drawing  sheet  and  drawing  view.  The  administrative 
information  supports  the  exchange  of  drawings  between  environments  in  which  configuration  management 
of  drawings  is  used.  The  following  application  objects  are  used  by  drawing_structure_and_administration 
UoF: 


- Approval; 

- Drawing; 

- Drawing_sheet; 

- Organization. 

4.2  Application  objects 
4.2.13  Approval 

An  Approval  is  information  that  indicates  a drawing,  drawing  sheet,  or  both  have  been  reviewed  for  data 
content  and  for  correctness  of  the  presentation  of  that  data  and  has  been  found  to  be  acceptable.  The  data 
associated  with  an  Approval  are  the  following: 

- Date; 

- Description. 

4.2.19.1  Date 

The  Date  specifies  the  date  on  which  the  approval  was  assigned. 
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4.2.19.2  Description 


The  Description  specifies  the  organization-specific  release  status  or  the  authorized  modifications  for  the 
revision  of  the  drawing,  drawing  sheet,  or  both. 

4.2.30  Drawing 

A Drawing  is  the  presentation  of  product  data  in  a human-interpretable  form  wherein  the  physical  and 
functional  requirements  for  that  product  are  presented  pictorially  and  textually.  The  data  associated  with  a 
Drawing  are  the  following: 

- Drawing_number; 

- Drawing_revision_id. 

4.2.30.2  Drawing_number 

The  Drawing_number  specifies  the  identification  of  a particular  drawing  by  an  organization. 

4.2.30.3  Drawing_revision_id 

The  Drawing_revision_id  specifies  the  identification  of  a particular  version  of  the  drawing. 

4.2.31  Drawing_sheet 

A Drawing_sheet  is  a logical  division  of  a drawing  into  a two-dimensional  area  for  the  presentation  of  product 
data.  These  divisions  correspond  to  sheet  paper  sizes  for  plotting.  A Drawing_sheet  contains  at  least  one 
Drawing_view  or  one  Draughting_annotation.  The  data  associated  with  a Drawing_sheet  are  the  following: 

- Sheet_number; 

- Sheet_revision_id. 

4.2.31.2  Sheet_number 

The  Sheet_number  specifies  the  page  number  for  a particular  drawing  sheet  and  its  location  in  relation  to  other 
sheets  of  the  drawing. 

4.2.31.3  Sheet_revision_id 

The  Sheet_revision_id  specifies  the  identification  of  a particular  version  of  the  drawing  sheet. 
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4.2.57  Organization 


An  Organization  is  a number  of  persons  or  groups  that  designs,  produces  and  supplies  products  and  services. 
The  data  associated  with  an  Organization  are  the  following: 

- Organization_name. 

4.2.57.2  Organization_name 

The  Organization_name  specifies  the  identification  of  a particular  organization. 

4.3  Application  assertions 
4.3.18  Approval  to  Organization 

Each  Approval  is  provided  by  one  or  more  Organization  objects.  Each  Organization  provides  zero,  one,  or 
many  Approval  objects. 

4.3.32  Drawing  to  Approval 

Each  Drawing  is  governed  by  zero,  one,  or  many  Approval  objects.  Each  Approval  governs  zero  or  one 
Drawing. 

4.3.33  Drawing  to  Drawing_sheet 

Each  Drawing  consists  of  one  or  more  Drawing_sheet  objects.  Each  Drawing_sheet  belongs  to  exactly  one 
Drawing. 

4.3.37  Drawing_sheet  to  Approval 

Each  Drawing_sheet  is  governed  by  zero,  one,  or  many  Approval  objects.  Each  Approval  governs  zero,  one, 
or  many  Drawing_sheet  objects. 
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Annex  B 


Example  mapping  table 


This  annex  contains  the  mapping  table  of  the  UoF,  the  application  objects,  and  the  application  assertions  for 
the  example.  See  annex  A for  the  normative  descriptions  of  the  apphcation  objects. 

The  AIM  entities  found  in  this  mapping  table  are  defined  in  ISO  10303-41:1994,  ISO  10303-101:1994  and 
ISO  10303-201:1994. 
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Table  4 - Mapping  table  for  drawing_structure_and_administration 
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Table  4 - Mapping  table  for  drawing_structure_and_administration  (continued) 
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Table  4:  Mapping  table  for  drawing_structure_and_administration  (concluded) 
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Annex  D 


Issue  1. 


Issue  2. 


Mapping  table  issues 


Mapping  table  syntax,  particularly  the  reference  path,  should  be  made  more  formal  to 
facilitate  software  support  for  mappings.  The  development  of  a formalized  syntax  for 
mapping  tables  should  be  considered.  A mapping  table  language  that  has  been  developed 
by  Industrial  Technology  Institute  of  Ann  Arbor,  Michigan  could  be  evaluated  and 
adapted. 

The  use  of  numbered  alternatives  in  mapping  tables  should  be  clarified.  They  are  often 
used  to  clarify  the  need  for  multiple  mappings,  but  there  are  no  guidelines  governing  their 
use. 
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